1. Creating a checklist for the test object intake
At a certain point, the test team takes delivery of the test object. This first activity has the aim of establishing
whether the delivery of the test object is complete, i.e. that it contains what was agreed with the supplier of the
test object – no more and no less.
The test object usually consists of all kinds of software components (each with a particular version), but a user
manual and installation guide, too, for example, may be part of it. The tester documents in the checklist which parts
are expected with the delivery. Besides information on the test object itself, the checklist also contains questions on
the delivery information. It should be apparent which changes the delivery contains and which parts are related to
which change. This prevents the test team from receiving changed software parts, while they have no change proposal and
therefore no test planned for it.
This occurs with specialist packages, in particular, because the supplier implements the change proposals of a number
of customers simultaneously, but only provides feedback to each customer individually concerning the changes requested
by them.
|
2. Creating a pre-test test script
After installation of the test object, a pre-test takes place in order to determine whether the test object is good enough
to start testing. In this activity, the testers prepare this pre-test by creating a test script. This can involve several
degrees of thoroughness. Below are a few examples:
-
Checklist with all the functions, which should all be accessible
-
For a number of representative functions, a simple test case with valid input (“good case”) is specified
-
Specification of test cases solely aimed at integration to check that the various parts can communicate with each
other. The data-cycle test is a good choice for this (see Data Cycle Test (DCyT).
The test cases may be obtained from the regular tests, but the results check is much more flexible. For example, it is
not important for the pre-test that the test case delivers a correct result, as long as it delivers a result and does
not crash, for example.
Examples:
-
For a banking application, the pre-test consists of a script of 25 end-to-end test cases.
-
With another financial organisation, the pre-test takes a day in which a tester executes the test cases which
contain the most important functionality.
-
A telecommunications organisation requests the supplier of the software to execute a number of end-to-end test
cases as a pre-test.
|
|